Hacking Christmas Gifts: Putting IoT Under the Microscope

If high-tech gadgets are on your holiday shopping list, it is worth taking a moment to think about the particular risks they may bring. Under the wrong circumstances, even an innocuous gift may introduce unexpected vulnerabilities. In this blog series, VERT will be looking at some of the Internet’s best-selling holiday gifts with an eye toward their possible security implications. Some of the risks discussed in this series may be over the top and even comical while others may highlight realistic problems you may not have considered.

Looking at a WIFI Microscope kit

In this first installment of the series, I’ll be discussing a WiFi microscope kit. There are, without exaggeration, dozens of listings for these devices on Amazon and most of them appear to be the same or very similar hardware with different brandings and varying accessories. Being the science geeks that we are, our team was quick to buy one of these devices when we saw it listed as a top-seller on Amazon’s holiday gift guide.

The microscope itself is compact with a wheel to adjust the lens and a few buttons for power, digital zoom, and to trigger image capture. It is necessary to connect a computer or smartphone to view and store images. From the quick start guide, Android and iOS devices can obtain a viewer app called “Max See” from their respective stores, macOS users can connect via USB and launch Photo Booth, but Windows users are directed to download a program for accessing the camera via USB or IP.

Reviewing the Security Implications

The question of whether additional software must be installed to utilize a device is an important question from the perspective of security. Installing software on a system generally widens the attack surface and, from a purely security perspective, should be avoided when possible.

In this metric, the fact that macOS can access the camera without additional software is preferable. For a Windows user, however, there is risk even before the software is installed because the instructions do not specify to use an HTTPS connection when downloading the camera software making it possible that an attacker on the network could replace the downloaded program with malware. Assuming an authentic program is downloaded, however, the risk of using this program to access the microscope via USB should be minimal.

With the Android and iOS use case, the attack surface is somewhat different due to the WiFi connection. The microscope works by acting as a wireless access point without a password and having the mobile device connect with the vendor’s app. This may mean that the phone or tablet remains in an insecure configuration where it may automatically and unexpectedly connect to an attacker’s access point in the future. This also means that a nearby attacker can inject malicious messages or completely spoof the microscope. An attacker who is nearby when the microscope is in use could likely deauthenticate the victim from the legitimate microscope and then produce a new access point impersonating the camera but sending malicious responses.

Multimedia and network protocol decoders are historically a common source for memory corruption flaws but these risks can be largely minimized by using well-tested platform libraries. In this case, however, extracting the contents of the Android application reveals a 7MB .so file which is responsible for handling device communications. A cursory static analysis of this binary reveals that it contains functionality for parsing RTP responses and MJPEG data. I didn’t spend the time to analyze this file and find concrete examples of vulnerability, but I have no doubt that there is something to be found.

In a worst-case scenario, an attacker could develop an exploit to achieve code execution on a nearby phone or tablet using one of these microscopes. Arbitrary code execution in the context of this Android application would allow the attacker to access the victim’s photos and whatever other messages are stored locally on the device.

Building Gadgets with Security in Mind

The chance that anyone cares enough to develop an exploit for this platform are slim and the chances that you yourself may be targeted by such an exploit are even slimmer. My point with this post is not to claim the sky is falling or argue against buying fun gadgets but rather to give an example of how to evaluate some less obvious risks from a given technology. This is an important perspective to maintain as we build and improve upon the systems we use every day.

As a developer or a vulnerability researcher, a main take away from this example is how the decision to create a custom parsing implementation rather than using system parsers can introduce vulnerabilities and create an excessive degree of overhead to maintain.